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iiBST-RACT 

Data flow languages are gaining importance because 
of their inherent asynchronous view of computation. Some 
extensions to the high-level data flow language Id (Irvine 
data flow language) are proposed to increase its effective- 
ness and expressive poijrer. Ihe proposed extensions are in 
accordance with the recent advances in the area of programm- 
ing language design and programming methodology. Seq,uential 
and mixed looping constructs are proposed which alongwith the 
existing parallel looping construct and with the proposed 
incorporation of generators provide a comprehensive and 
flexible set of looping constructs. Stream structures are 
proposed to model the arrays of streams. Their usefulness in 
the resource management to maintain a variable number of 
CLueues is discussed. To aid in program abstraction and to 
enable a programmer to define his own language, tailored to 
his needs, programmer defined constructs (pdcs) are incorporated 
The approach used to incorporate programmer defined constructs 
has some similarities with the well known conditional assembly 
of macros used in low level languages. Usefulness and 
implementation of some of those aspects in conventional 
languages is briefly discussed. 



CHAPTER 1 


INTRODUCTION 


1 *1 Objective 

Dataflow languages are gaining importance because 
of their inherent asynchronous view of computation and thus 
their ability to act as a suitable semantic basis for 
parallel computation. The objective of this thesis is to 
propose some extensions to a hi^er-lovel dataflow language 
Id [AG-P783 (Irvine dataflow language) developed by the 
Dataflow Architecture Croup at University of California, 
Irvine. Proposed extensions enhance the capabilities of Id 
looping constructs, provide a general model to maintain a 
large and variable number of queues to deal with the problems 
of resource management, and enable a programmer to define 
his own higher level constructs using available Id schemas. 
Our proposed extensions should be viewed in the context of 
the recent advances in programming lar^guage design and 
programming methodology some of which arc briefly discussed 
in Section 1.3. A reader who is familiar with the dataflow 
languages, their advantages over conventional languages, 
and Id may skip rest of this chapter and the next chapter. 
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*2 Oonventional lanA^ua^es vs d at af lot-7 lan^uaKes and 
dataflow concepts 

With the speed of somi conductor devices reaching th.eir 

limits due to electrical propagation delays, parallel 

computation has emerged as the only hasis to speed up compatatioi 

to solve largo and complete prohlems . Many computer systems 

like ILLIAC IV, GDC STAR-100, CRAII etc. have been built todate 

to exploit the power of parallel computations, Hovrevor, they 

* 

are still based on conventional Von Neumann architecture 

* 

characterized by sequential control and memory cells, and thus 
require either complex software or hardware mechanisms to 
bring out the parallelism in the program. A new dimension is 
added to the problem by the recent advances in LSI technology. 
Largo numbers of inexpensive processors are now available 
and thus "distributed processing" among many distinct 
processors with essentially autonomous control is gaining 
favour. However, it is now widely recognized that under the 
constraints of conventional architecture and languages it is 
extremely difficult to efficiently utilize a large number of 
processors, since sequential control inhibits asynchronous 
behaviour and existence of memory potentially requires 
proper synchronization of accesses to each memory cell C Don 73 » 
GIMT 74, ¥en 75, SM 77, AG 77b, AG 77c etc,]. In past many I 

control primitives .for parallel computation (GALL and WAIT i 

Gonventional architecture and conventional languages are used 
intorchangably as languages reflects the characteristics of 
architecture. 


in PL/I, Goloegiii-coend etc.) and synchronization schemes 
( Semaphores [Dij 68] etc.) have been proposed as extensions 
to conventional languages. Ho-wever, program Tfjritten using 
these constructs arc limited in the degree of parallelism 
they exhibit. Thus to exploit the capabilities provided by 
recent technological advances, we need an asynchronous view 
of computation. 

Dataflow languages have been proposed to give such 
a view of computation [Den 73, GIMT 74, AG 77b, AGP 78 etc.j.They 
are based on the observation that an operation should be execu- 
ted as soon as its input operands are available. The attract- 
iveness of dataflow schemas as the semantic basis of parallel 
computation lies in two properties; 

1 . an instmction executes when and only when all 
operands needed for that instruction become 
available , 

2, instructions at whatever level they might exist 
are purely functional in nature and produce no 
side" effects i.e. there is no memory in conventional 
sense [AG 77b, Don 73] • 

Thus dataflow program is a set of partially order od 
operations on operand values where the partial ordering is 
determined solely and explicitly by the need for intermediate 
results. Dataflow languages offer several advantages 
[Den 73, KOS 73, AG 77b, AGP 78] over conventional programming 
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languages such, as absence of variables, highly modular 
program structure and inherently functional nature. Thus 
they are well suited to describe and implement asynchronous 
behaviour req^uired by many complex systems such as operating 
systems. Several dataflow languages and schemas [Den 73, 

EOS 73, Bah 72, 1<M 66 etc.] have been proposed. In 
particular dataflow language proposed by Dennis [Den 73 ] is 
well suited as a base language for a dataflow machine. Recent 
efforts have been in the direction of developing higher 
level languages so that dataflow becomes an attractive alter- 
native for the end users. ¥eng [ VJen 75 ] proposed a Textual 
Dataflow language xirhich incorporates recursive schemas and 
streams. Zosinski [ Kos 731 and Bryant [Bry 77] have also 
proposed languages based on dataflow concepts. Recently 
Hankin etal [ HOS 78] have proposed a language CAJOLE which 
is still in a developmental stage. However, it allows the 
programmer to define his own nexf constructs. Dataflow 
Architecture group at University of California? Irvine has 
proposed a higher level datafloxf language Id and a computer 
architecture suitable for its execution t ACP 78, AC 78]. 

Id is of a more advanced nature and incorporates ideas of 
streams, monitors, nondetcrministic programming, abstract 
data types and operator extensiality . In this thesis we 
will look at some of these features of Id more carefully. 
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*5 Progrsanming laA^uages in general 

In recent years production of reliable software has 
drawn a lot of attention. It has been noted that conventional 
languages are not well suited for program verification and 
for writing reliable complex software systems. Structured 
programming has been proposed to bring order and structure in 
the otherwise chaotic world of programming languages [ Bac 78], 
It is now well understood that development and maintenance of 
complex software systems is facilitated by the preservance 
of the problem structure in its solution and by modularization, 
to localize the subsequent modifications. Drive is towards 
a functional view of computation rather than a procedural 
view. Current interest in data abstraction and control 
abstraction [ISAS 77, STfi/L 771 points in this direction. To 
aid the verification of programs, the structure of looping 
constructs is being studied. It has been proposed that 
initialization of loop variables, loop terminating conditions 
and incrementation of loop variables should be explicitly 
stated and grouped to aid in program verification [ Pra 78], 
Languages whoso semantics is more closely ahin to mathematics 
have been proposed to simplify program verification 
[ Gut 77, A¥ 77]. 

Another area which is being extensively explored, 
concerns with the linguistic aspects of the problems related 



to resource management [ JL 76] , A higher level language 
especially a language suitable for distributed processing 
should have capabilities to handle harduane and software 
resources. Hero also we see a drive towards more encapsulated 
and functional approach ( semaphores [Dij 68 ] to monitors 
[Hoa 74 ] ). 

¥ith the Bachus' proposal [Bac 78 ] a new school of 
thought is emerging in the field of programming language design. 
His main objection against the conventional programming 
languages is that they are growing over more enoromous, but not 
stronger because of their inherent defects at the most basic 
level. They are founded on word - at - atimo prograimning 
inherited from their ancestor Von Neumann computer and their 
semantics is closely coupled to the state transition. They 
have more rigid parts and loss variable parts because of their 
closed coupling to the state transition and dividing tho 
pi’ogramming into a world of statements and world of expressions. 
I^/hereas, the world of expressions is orderly and has useful 
mathematical properties, the world of statements is chaotic. 
Because of these aspects they are unable to effectively use ; 
powerful combining forias to build now programs from tho existing 
ones, and they lack useful mathematical properties. Ilis 
proposal is to adopt a truely variable less functional program-; 
ming language which has loss rig id parts and more variablo 
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parts. Such functional programs are often nonrepetitivo and 
nonrocursive, are hierarchically constructed , do not namo 
their arguments and donot require complex procedure declarations. 
Ihinctional programming can easily use higher level programs 
to huild still higher level ones. . Since prograr-is , their 
sema^ntics, and their realizations are defined in the same 
language, a simple algebra of programs can be used for program 
transformations . 

¥e believe that some of the aspects discussed above are 
important for the next generation of programuiing langusges -which 
will be required to deal with systems of still-yet-unimagined 
complexity, : 

1 Overview of the thesis 

Since the thesis extensively uses the presently available 
Id constructs to describe proposed extensions, Chapter 2 briefly 
describes Id and its constructs. Block expressions, conditional' 
expressions, loop expressions, procedures, monitors, and 
programmer defined data types are discussed. To show the use 
of some of these constructs. Id program to compute Fast Fourier , 
Transform of a signal sequence is described. 

Chapter 3 deals with sequential looping constructs, 
mixed looping constructs and generators. In alternate ; 

translation of for loops using for each loop and generator is 
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discussod* This view of f or loops nakes the trahslation of 
nixed for loop cor struct s easy, A simplified translation of 
for each “ while loop is also discussed, and, its usefulness 
in the controlled generation of the eloments in a for - while 
loop and in a pdt , is shown. 

Chapter 4 doscrihos stream structures which are useful 
in maintaining a variable and a large number of queues. Dynamic 
stream construct of Id is reviewed and some base language oper- 
ators aro extended to allow streams as creation time parameters 
for Id monitors. Usefulness of the stream structures in the 
resource management problems is shown through an example. 

Chapter 5 discusses the programmer defined constructs, 
which enable a programmer to define his own constructs and 
aids in program abstraction. Syntax for its definition and 
its use, and, its implementation is described. To bring out 
some of the rolevront points and limitations several examples 
are discussed. 

In Chapter 6 we present our conclusions and observe that 
some of the concepts discussed in the thesis can also bo 
incorporated in conventional languages to enhance their 
capabilities . 



CHAPTER 2 


Ids A BRIBP INTRODUCTION 

This chapter is intended to naho the reader familiar with 
the high level dataflow language Id (Irvine dataflow) together 
with the syntax and . the tindorlying seuaiitics of its constructs 
IA&P77, AGP78]. 

2 • "1 Id and the underlying model of execution 

Id is a "block structured, expression oriented, single 
assignment language whoso syntax resembles Algol-type of block 
structured language. Id provides facilities for resource 
handling via da,taflow monitors 5 incorporates data abstraction 
ncchanisns (i.c. programnior defined data typos), and is 
extensible • 

Id like any other dataflow language is based on the 
principle of dividing computation into smaller sub computations 
Called activities which na,y bo executed by independent 
processing elements. Every Id program is compiled into a 
corresponding program in the base language which is an ordered 
graph consisting of operators interconnected by directed linos 
that transport values in the form of tokens, A variable in 

This section or rather this complete chapter relies heavily 
on the description of Id given in IAUP78] . 
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a,rL Id program does not represent the iiaiiie of a memory coll, 
rather it is the name of a line in the ba.se language graph 
along which the value travels. Id variables are not typed. 

The internal representation of va,luos is self identifying and 
thus, type is associated with a value and not a variable. A 
given Variable in Id or a line in program graph is either a simple 
Variable or a stream variable [ hen 75 ] « A simple variable 
carries a single token to each instance of an operator's 
execution, while a stream variable carries a linearly ordered 
sequence of tokens to each instance of on operator's execution. 

Id Variables are strongly typed as fai* as streams are concerned. 
Throughout the thesis simple variables will be denoted by 
lower case letters and stream variables by upper case letters. 

Base language programs corresponding to Id programs arc 
executed on a dataflow machine using Unravelling Interpreter ^ 

tAGTYal. The unravelling interpreter dynamically removes i 

ordering between operations due only to tine, while retaining 

i 

orderings required by the need for partial results. This 
scheme of interpret a,tion does an automatic unfolding of loops 
and permits simultaneous execution of distinct invocations 
of the same operation. This brings out far more asynchrony 

I 

then what is normally possible in a dataflow language [Don 75, ^ 
AG77a ] . Underlying dataflow machine does not have memory in ' 
the convntional sense. The values arc carried by tokens. ' 
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Memory is used only to store values that ahc too largo to bo 
moved efficiently; instead a pointer to storod value is cairiod 
by the token. Thus existenco of mornory is completely trans- 
parent to the Id prograjjimer , 

2 *2 Id values and basic schemas 

Id values are of nine typos; integer, real, boolean, 
string, structn.re , procoduro definition, monitor definition, 
monitor object, and errors. First four nood no explanation, 

¥g -will explain structures here, rest of them uill be treated 
in later sections. A structure value is either the empty struc- 
ture A or a sot of < selector; value > ordered pairs. A 
selector is an integer, real, boolean, or string value; a value 
is any Id value. There are exactly tvfO operators defined over 
structures — SELECT and AP FEND [ AGP78 ]. The important thing to 
note is that an apnond operation always creates a logically new 
structure, and the original structure may enjoy a simultaneous 
existence. Multiple selectoi’s are allowed. 

¥o explain three basic schemas in Id; block expression 
conditionals, and loops. 

2,2,1 Block expressions ; 

Any Id program can bo written as a list of expressions. 
However, it is convenient to break a computation and identify 
certain partial results. An example of block expression is 
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Xfj (x lo * 2 + al 
J ^ 2 * a 

return x + j,j) (2.1) 

The in~pnt s to the block expression arc those variables 
which are roforencod but not assigned in the block and outputs 
(ordered) are specified by return clause. The compilation of 
expression is shown in Figure 2,1 . An as signmont st at oment 
names the line in corresponding base language graph. Id limits 
the scope of names to the block in which they arc defined. 

Thus x,y have different values inside and outside the block in 
expression (2,1), a constant like 2 in Id does not represent 
a Value but function that produces that value as its output 
regardless of the value of the input. Box C in Figure 2.1 
represents such a function, 

2.2,2 Conditional expressions ; 

A conditional expression in Id is of the form 

( if p(x) then f(x) else g(x)) (2.2) 

Its base language translation is given in Figure 2.2. The ! 

I 

SWITCH operator passes the token coming on data line to the 
T branch or the F branch depending on whether token on control 
line Carries the value true or false . If any of the branch 

I 

(T or F) is not connected and the control input dictates that i 
branch to be taken, then the data token is simply absorbed. The; 








t 



/ii'_nAre 2,2 Oompilotion jC die oood it tonal 
expresoion (2,2), 
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^ operator nerges tho tvfo branches of conditional expression. 
A conditional expression needs all of its inputs for execution 
regardless of tho branch to bo taken. In a. conditional 
expression tho then clause and the else clause should contain 
equal number of expressions. Conditionals can also bo written 
in the statement form. Thus expression (2.3) and expression 
(2.4) are e quivalont . 

( if p(x) then j f (x) ; z 1 else ^ y'^g(n)5 z ■«-0) (2,3) 

y,z-<-( if p(x) then f(x), 1 olso g(x), 0 ) (2.4) 

2*2*3 Loop expressions ; 

Basic loop construct in Id is a while loop (loops 
involving streams aro different) . A while loop is given in 
expression (2,5) and its compilation in Figure 2,3 

( initial i 1 5 sum 1 
while sum :< s do 
new i i + 1 ; 
now sum sum + i 

return sum , i ) (2,5) 

Variables initialized in the initial part and all loop 
constants such as s circulate in tho loop domain. For tho next 
iteration of tho loop thoir new values aro defined by loop 
body. A default for loop constants is that thoir new values 
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-1 -1 

arc sane as old va,luGS. The operators 1, L , D do not 
aflect tlic values of the tokens passing through thorn. They 
ar*c used by the unravelling interpreter to manipulate activity 
names so that tokens belonging to different instantiations 
of a loop do not get mixed up with the tokens belonging to 
different iterations of a loop instantiation, new i is used 
to label a line which is different from i ahd does not violate 
the single assignment rule. 

Id supports many kinds of looping constructs such as 
for loops? f or ~ while loops etc. However? they a,ro compiled in 
form of a basic while loop. Expression (2.6) gives a for - while 
loop whose equivalent while loop is given in expression (2.7). 

( initial x f(z) 

for i from ^ 1 n while p(x) do 

y g(i) 5 

now. X f (x)+y 

return x) (2,6) 

( initial x fix) 

while i<_n A p(x) ^ 
y g(i) 5 
now X -t- f(x) + yi 
new i i+1 


retiirn x) 


(2.7) 



A "basic looping construct involving streajas is given in 
expression (2.8), 

( initial s a 

for each, x in Xj y ^ Y whi le p(Xj,y) do 
nsT.^ s s+x+y? 
z 4-f(x,y); 

2 ;< t then h next p 

else h X 

return s, all z, all h but X) (2,8) 

There are raany points brought out by this expression 

which are relevant when dealing with streams. A for each 

loop operates on all the elements of a stream. Expression 

(2,8) shows a parallel looping construct in which for each 

iteration of a loop an element from X and an element from Y 

are taken, loop terminates when predicate p is satisfied, or 

either of the two streams runs out of tokens, abb z is a 

stream producing construct and returns a stream, containing 

abb the vabues of z, but X performs what one intuitively 

expects it to do: it filters out X's from the stream all b, 

next P construct gives next element from the stream P, when 

asked, and thus avoids circulating the streamP. next only 

has meaning when it is inside a conditional construct which is 

embedded in a loop expression. Compilation of expression (2,8) 
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is too involved and is given in Sections 4*2, 3. 2 and 4. 2, 3. 3 
of [AGPTS ] . Ve will show a simpler implementation of the 
loops involving next in Chapter 4. 

2 • 3 Procedure definition and application 

A procedure definition in Id is a constant value and 
it may he created by xfriting : 

P procedure (x) x > 1 then x - 1 

else X + 1 ) (2.9) 

X is a formal parameter, ac.d the expression is the 
procedure body, p is the name of the line along which the 
tolren carrying the procedure value will travel. In Id two 
operators are defined over procedure values; 

APPLY and COMPOSE. Apply applies the procedure definition 
to a list of actual arguments. ¥e write an application as 

res ■*- apply (p, arg ) 

where arg is actual argument. A syntactic shorthand is 
res -e- p (arg) 

The primitive apply is implemented as two base 
language operators; A and A as shorn in Figure 2,4. Ihe 
A actor accepts tho procedure definition and creates an 
instance of its execution. It then sends the actual 



instance of 
proceuuro p 
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arguments to this instance. The results of computation are 
“1 

returned to A ahd the instance of the procedure is 
automatically destroyed. Distinct instances af*e created 
for the application of the same procedure at different 
places. 

Compose operator takes the input procedure value and 
"freezes" one or more of the procedure's formal parameters 
to particular actual values. For example, in 

a nrocedure (1,0) (h * c + l/c); 

^ compose <ay<2>> (2,10) 

d behaves as if programmer had -written 
d •+• procedure (c) (2 c + 2/c) 

It is possible to give a name to an Id procedure. This 
is useful in siting recursive procedures. Whenever a named 
procedure is applied its definition is also passed as ah 
argument. Expression (2,11) gives a recursive procedure to 
calculate factorial function, 

y procedure f(n) (if n = 0 then 1 else n ^ f(n“1 )) 

( 2 . 11 ) 

compose and named procedures are useful in programmer 
defined data types. Procedure's arg-uments are not limited to 
simple Variables, stream variables are also allo-wed. 
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* 

2 • 4- Datafloxf monitors 

The concept of a dataflow monito r [ AG-P77, AG-P78 ] 
was introduced in order to allow nondetermini stic behaviour 
generally encountered in resource management. Expression 
(2,12) assigns a dataflow monitor definition value to 
Variable md. 

md monitor (s ) 

( entry REQ ^ 

RES ( initial s s^ 

for eac h req REQ do 

nmf s, ans f(s, req) 

return all ans 

exit RES) (2,1 2) 

Many instances of monitor objects may be created from 
this monitor definition. Creation of a monitor instance 
is done by 

cJ^Qate (md,a) (2.13) 

A programmer refers to the monitor object by writing 
me. a is the initial state passed at the creation time. An 

I r— -T--,Mrr -r-f ni rr— . ,■ - p— '■***'****' 

In [ AGP78 ] word manager is used in place of monitor. 
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instajice of a monitor is not created and destroyed for only 
one invocation, but may lo reused arbitrarily during its life 
span Tdj'' sending to it arguments, which will be processed in 
a FIFO order. There exist only one instance of me and all 
the uses of mo refers to that instance only, 

A monitor instance is shown in Figure 2,5. The entry 
operator receives all requests and forms a stream by merging 
the requests nondoterministically . This stream is passed to 
the monitor’s body. The exit operator converts the output 
stream to simple tokens and returns them to the place from 
where requests originated. 

To use a monitor object we write 

z use, (me, y) (2,14) 

The compilation of this statement is given in Figure 

2.6. The U operator sends the argument (y) to the domain 

“1 

indicated by me. The result is returned to U operator 
and assigned to variable z. 

Since the internal state of a monitor acts as a 
memory, the processing of a particular request may depend on 
the history of the previous inputs sent to the monitor. 

Id provides another nondeterministic operator; merge . 


It merges the streams specified in its argument list 
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nondetermini Stic ally and creates a now stream. Ixpressicn 
(2,15) shews the use cf mer^e ♦ 

C ruQTf^e (A,B) (2.1 5) 

2 , 5 Pregrammer defined data typos 

In Idj a procedure definition value is treated 
exactly like any other value. This general view of a 
procedure allows Id to provide some very sophisticated higher- 
level concepts while requiring only minimally expended 
lower-level mechanisms. These higher-level concepts include 
programmer-defined data types (pdts) and operator extension- 
ality so operators such as "+*' ir^y he interpreted at 
execution time in the context of the types of their arguments. 

Expression (2,16) gives a pdt ’set' with four 
operations. Operation decides set memhership and 

returns a boolean value, ’+’ denotes set insertion and 
returns a new set value. New set value is created using 
the procedure set-gen, ’U' and ’ n ’ denote set union and 
set intersection operations. 
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tirocedure set-gen (s,l) 

(y-«- procedLiro set (! function! f, ! arguments! UjV, 

! set array! s, ! cardinality ! 1, set -gen) 
( if f= "e " then ( initial t -t- false ; 

for i from 1 1 • while t ^ 

new t -t- s [ i ] = V 
return t) 

elsei f f = then (if lel (u,v) then u 

e lse set-gen( s+ [l•^-1 ] Vj 

1+1 )) 

elseif f = "U" then ( initial h ■«- v 

for i from 1 1 ,dp_ 

new h b+ s [1] 
return h) 

elseif f =" " then ( init ial b ^ set -gen ( ) 

for i from 1 to 1 dp 

( if I e I (w,s [ i 1 ) thon new b •*' b+s [i] ) 
ret -urn b) 

else error; (< 'invalid set operation', f>)) 
return ( if s =? then compose (y, < ,,, A ,0, set-gen > ) 

else compose (y, <,,, s, 1, set-gen>~))) 


( 2 . 16 ) 
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Actual values of sets axo created Toy calling the 
procedure set-gen. The procedure set-gen returns a procedure 
Value 'set' -with two frozen parameters s and 1 which 
characterize that set. Thus a pdt is always a procedure. 

To generate a new set a we wite 

a -^-set-gen (s,!) 

whore structure s contains the elements of a and 1 is the 
cardinality of a. Similarly to create an empty set we write 

a-fr- set-gen ( ) 

An operation, such as set insertion (+), can he 
performed by writing 

b^l +1 (a, 17) (2.17) 

Expression (2.17) creates a new set b and it is 
translated as 

"t* •^ apply (a, +, a^17) (2.18) 

Expression 2,18 can a7-so be written as 
b 4- a + 17 

and in this case the meaning of operator + is determined 
at e xe cut ion time. 

If the operator + receives a procedure value on line 
a, it dynamically changes itself to an annly operator to 
evaluate the expression of the form (2,18). 
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2 . 6 An example 

In the previous sections we have discussod the mechanisms 
provided by Id, To shovr tho use of those mechanisms, we give 
an Id program to compute the Fast Fourier Transform of a 
discrete signal sequence. The signal sequence is represented 
as a stream. 

procedure fast-fourier (X, j,n,w) 

!Xis the stream of the signal samples, 

n is the number of the samples in 

the original stream, w contains the 

the Values of , whero ¥i = 

_ .2jr ^ 

e“^ n , and j=2^, where i denotes 
the level at which we are working. ! 
Init ially 3 should be 1 . ! 

(i£ empty ( rest (X)) then X 

! stream is divided into two parts containing odd and even 
numb er ed samples. 
else ( P,Q ( initial flag true 
for each x in X ^ 

(If. flag then p •«- xjq X ) 
else p -(-X ; q x) ; 
new flag 1 flag’ 
return all p but x ? all q but x ) ? 

S -(-fast-fourier (p, 2*3, n, w) ; 

T -^fast-fourier (Q, 2*3, n, w) 5 
U,V ^ ( initial i 0 

for each s in S; t in T ^ 
a ■(- w[n, i*3 ] -ft 5 
u ■(- s + a ; 

V -(- s - a ; 
now i^i 1 
return all u, all v) 
return con ca tenat e (U,T))) 


(2.19) 
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Keeping the asynchronous input and output hehaviour 
of the streams in mind, a rough analysis of the above program 
will show that it tahes 0 (n+log 2 n) time, whereas, a corres- 
ponding program on a sequential machine will take 0(n log 2 n) 
time [ KAlTQh]. However, the above program requires atleast 
0(n) processors to execute in the time complexity of 
0(n+log2n), This proves the point that Id is able to exchange 
processors vjith time. As a passing point wo would like to 
mention that most of the algorthims, such as morge-sort 
[LCATTSa] etc., show this tendency. However, certain conventional 
algorithms which aro efficient on sequential machines turn out 
to bo inefficient xdaon translated in Id. Thus it is 
reasonable to assume that to exploit asynchrony inherent in 
the problem it is not sufficient to translate existing 
algorithms into Id or any other dataflow language. Instead 
new algorithms must be invented and analyzed to derive 
benefits of asynchrony [Mai 78], 



CHAPTER 5 


sequential loops, mixed loops, and generators 

In tiiis chapter we discuss many aspects of looping 
constructs in Id and show that the idea of generators and 
iterators can he incorporated in Id very easily* As a conplo” 
ment to parallel loops wo propose sequential looping construct, 
that is loops of nested nature, and generalize these constructs 
to include any combination of sequential and parallel loops 
i,eo mixed looping constructs. Sections 3. 2 and 3.3 deal with 
sequential looping constructs and their efficiency considerations. 
Section 3.4 explains syntax and translation of nixed for each 
loop constructs. Section 3.5 shows how the idea of generators 
can easily be incorporated in Id. Section 3.6 presents an 
alternate translation of for loop in terms of for each loop 
using the concept of a special generator i to This view of 

for loops makes the translation of nixed for loop constructs 
easy. Section 3.7 discusses a simplified translation of for 
each - while loop. Section 3.8 extends the ideas developed in 
Section 3.7 to control the generation of elements in a for - while 
loop and in a pdt, Einally Section 3.9 shows how the ideas of 
sections 3.4, 3.6, 3.7 and 3.8 can be used to translate mixed 
looping constructs with while clause. 
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5 • ^ BackATound and motivation 

As described in Cliapter 2 , Id [ A&P 78 ] provides many 
kinds of looping consbructs to operate on simple as well as 
stream variables. Por tke sake of comprehensiveness we list 
them below o 

(s-) whil e p(x) do where p(x) is some boolean exx^i'ession 
i from j to_ k ^ 1 do and 
for i from j to k ^ 1 whil e p(x) ^ 

( ^ each x i n~ Z ^ "" 

each x in Z5~"y in Y do 

.e ach x in X? y in Y while p(x,y) 

Loop expressions like any other expressions in Id can be 
nested to any arbitrary depth. At present, loop expressions 
involving next in Id are different from (a) to (e). However, 
with a simpler implementation of next described in Chapter 4 
(section 4.5)? the present discussions will be valid to loop 
expressions involving next also. 

Our motivation to go for sequential and mixed looping 
constructs is to make prograjnmer ’ s task easier. Consider an Id 
program to sum all the elements of a n.xm matrix given in 
expression (3.1 ) . 
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( initiaiki ■ s'om 0 
for i from 1 n dp 

nei'T srm sism + ( initial sum 0 

for 3 from 1 to m do 
new sum ^ sum + a [ i » 3 1 
return sun) 

return sum ) ( 3 • 1 ) 

Id forces one to initialize the sum twice. One can 
imagine the programmer's hurden when the levels of nesting 
goes loeyond three or four. Syntactically it will be more 
convenient for a programmei* to write 

( initial sum 0 
for i from 1 n, 

3 trom 1 to m do 

new sum sum + a [ i , 3 1 

return sum) (3.2) 

However 5 translation of above construct is rather 
difficult in terms of existing compilation of for loops. The 
translation is considerably simplified if we view 1 to n as 
a generator generating successive values of the loop variable 
i. Another motivation to incorporate generators is to extend 
looping constructs to iterate over the elements of a pdt 
without giving undue emphasis on the order of enumeration. 
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Hiding tlio order of emmorat ion is a useful concept because 
in uany data structures, such as sets, there is no implicit 
Ox’doring (in na.thomatical sense) defined over their elements. 
CLU [LSAS77 ] , ALPHAHD [ BWhll land EUCLID ILIILIIP77 jalrcady 
provide such an extended view of looping constructs to iterate 
over the elements of an ahstrant da,ta type. 

3*2 A sequent ia,l looping construct for ID 

Since a somicolan is used to define a, parallel looping 

construct (sec (d) and (o)) lot a contra sep, grating two 

clauses of a loop (as in expression (3.2)) define their 

* 

sequential or nested na,tui"e • Hence the meaning of 
for each i in 1 , 3 in J do 

is that for each element of i talcc each element of J one by 
one and execute one iteration of the loop. Hence the loop 
body will be executed 1 l] X j J 1 times as opposed to mini] I j , 
jjlltimes (as in the case of a parallel loop). Implementation 
of a sequential loop is quite straightforward and is explained 
below in terms of an equivalent Id program not involving such 
a construct , 


file use of comma here is different from UCI dataflow 
ITote 11 (revised). 
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( lnitln.l X- *■ 

for eacli i in. I, j 3^ J do 
new X -t-f (x,i , o) 

return :c) (3.3) 

TliG loop in expression (3.3) can be implejxented as 

( initial X Xq 

for each i in I do 
new X -«-( initia l •"X-t-x 

for oach j in J do 
new X f ( X , i , 3 ) 

return x) 

return x ) (3.4) 

There are some subtle issues involved in the correct 
translation of expressions contained in the return clauso of 
expression (3.4). An eo^ually efficient but somewhat more 
straightforward translation of (3.3) is given in (3.5). The 
expression in (3.5) does not affect the body of the loop. 

Only the input streams I and J are suitably enlarged to I' and 
J’, each of which has a length I ll xl ji, ¥e prefer to 
translate expression (3.3) into expression (3.5) rather than 
expression (3.4) as the scheme of expression (3.5) is useful 
in translating mixed looping constructs. 
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(I ' , J ' ( for each, i in I ^ 

I',J' ^ ( for each .1 in J do 

rettirn all i , all d ) 
return all I ' ? all J ’ ) 
return ( initial . ■ x. Xq 

for e ach i in I • 5 .j in J * do 
new X ^ f (x,i, j) 

return x) ) (3 *5) 

The construct return all X returns a stream as opposed 
to a stream of streams, 

3*3 Efficiency of sequential loop expression 

Expression (3.2) for summing all the elements of a matrix 
Can he translated into expression (3.6) in a mechanical way. 

( initial • sum *«- 0 
for i from 1 n do 

new sum ( initial sum sum 
for d from 1 to m do 

now sum sum + a [ i , d ] 
return sum) 

return sum) (3.6) 

Eote that expression (3.6) is considerably less 
asynchronous than expression (3«1) due to the fact that all 
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the additions in (3.6) arc done sequentially. In expression 
(3.1) summation of elements within a row is still sequential 
hut it proceeds simultaneously for all the rows, './hilo 
expression (3.1) will take 0(n) time, expression (3.6) will 
take O(n^) time. It is possible to mechanically transform 
expression (3.6) into expression (3.1) hut this is quite a 
difficult task because it involves meanings of man37' non-control 
operators in Id. It is reasonable to assume that in general 
when nested loop expressions are expressed as sequential loops 
a loss of asynchrony is involved. Thus the ease in siting 
may come at the expense of efficiency. 

3»4- Mixed looioing constructs 

In order to goneralis;© parallel and sequential looping 
constructs wo consider the following two proposals, 

(i) each (i in 1; j in J), (k in K; 1 in L) ^ 

(ii) for each (i in I, 3 in J) ; (M in 1 in L) ^2. 

The loop in (i) should go through min{lll , | j1 }X 

min{|Kj , I Ll) iterations while the loop in (ii) should go 
through min{ I I| X jJ.],, \K\ X | L | }itera-fcions . Semantics of 
expressions of type (i) are given in expression (3.7) while 
the meaning of (ii) is given in expression (3.8). 
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(I*, J', K', L* ( for each i in I , j in J do 

I ' , J\ IV , L ' ^ (for each k in K; 


1 in L do 

return all i , all j , 
all k, all 1 ) 

return all I ' , ^1 J ’ , aZ 1 K ' , all L ' ) 
r eturn ( for eac h i in I ' ; j in J ' 5 k ^ K ' ; 1 ^ L * ^ 


.)) (3.7) 

(IS J * ( for each i in I do 

IS J ' ( for each .1 in J do 

return all i, all 3) 
return all I ‘ , all J ’ ) 5 
K ’ 5, L • ( for each k ^ K 6 ^ 

Z ‘ , 1 ’ ■*■ ( fpy each 1 in 1 do 

return all k, all 1) 
return all Z ' , all L ' ) 

retTrrn ( for each iini*, jinJ’jk^Z’j li^L’ do 


.)) 


(3.8) 


It is clear from these examples that we can build quite 
complex for each constructs by combining i in I type of clauses 
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either in a sequential uay or in a parallel way. Iraplciient— 
at ion of such comploz for oach constructs requires no 
additional base language operators. 

Stroafi producers as generators 

As pointed out in Section 3.'i a useful control 
abstraction present in OLU [LSAS77 J and ALPEAED [ SWL77 3 is 
that of a generator. It offers a of hiding the order of 
enumeration of the olcnonts of an abstract data type when 
such an order is unnecessary. Per example a generator may 
onunorato all the elements of a set or all the elements of an 
array for addition without mahing the order of enumeration 
explicit. A related problem is to onumora,te the olomonts of 
a programmer defined data type when its internal structure 
is not known. 

Something equivalent of generators can be defined very 
easily in Id using streams. In general any oxnrossion producing 
a stream can be troaf ed as a generator, Ihe elements of a 
stream X can be enumerated using a for each x in X construct. 
Since the order of enumeration depends upon the construction of 
X, the problem of hiding the order of enumeration becomes the 
problem of hiding the generation of X, Since X will be gener- 
ated by an expression and the internal funebioning of no 
expression in Id is visible from outside, the problem of hiding 
or abstracting is essentially solved. Wo ela.borato this point 
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furtiiGr by giving enaniplos. Suppose we want to sum the elements 
of a sot s ¥here s is a programmor definod datatype in Id, We 
could accomplish this in the following way in Id . 

Define a function "onumerat o" on sets and include it in 
tho procedure sot-gen (sec Section 2,5) . I'he proccdui’o set 
(produced by procedure sot-gen) when supplied with "enumerate" 
as a parameter would produce a stream containing all tho elements 
of the set, I'he order of enumeration will depend upon the 
definition of the function "enumerate" inside the procedure set, 
Tho programmer using sots would just write 

for each e m | enumerate | (s) do 

Since the definition of a procedure application in Id 
allows streams to be input as well as output there is no problom 
in generating a stream from a pdt , It is also clear that such 
enumeration procedures can be defined for any pdt. However, wo 
can avoid generating a stream from the pdt, if wo desire so, by 
breaking the operation into t-^ro parts. Define a function on a 
pdt that gives all its elements stoi’ed in a linear struc'ture 
with selectors 1 to n. A procedure that converts such an array 
into a stream is trivial to T-nite. This method, however, fails 
with those pdts that have countably infinite number of 
elements. ¥e will discuss this problem further in 


section 3.7 
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5 • 6 Azi altoriiato translation of for loops usinA a special 
generator 

Values of i generated Toy the for loop 
for i from j Ic ^ 

Can also be modelled as the following stream 

I -e- ( initial i j 
while i :< k do 
now i -t- i+1 

return all i) (3 •9) 

The stream I can now bo used in place of from .1 to k as 
for each i in I do 

Event hough the loop fo r i from j k do results in a different 
base language translation, the answers produced by two loop 
expressions will bo identical except in one detail. Suppose 
the last valno of i is to bo returned from the loop. The 
from j k loop will produce the value k+1 while foi* each 
i in I loop will give an erx’or. Several solutions to this 
minor problem are possible and zre will not discuss them here 
any fui-thcr, ¥e would like to point out that both for loop • 
ab-d for each loop in this case are equally efficient. 

One might be wondering about our motivation to 
translate for i from 1 n typo of loops into slightly more 
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complicated for each i in I t3'-pe of loop. As ifo hope- to show 
in tho nezt few sections this approach helps considero.hly in 
translating sequent ial looping constructs of the type given in 
expression (3.2), Without this technique of converting for 
loops into a for eac h loop implementation of tho following 
construct is extremely difficult. 

for (i from 1 n, 3 from 1 to m) | 

( ^ 1 t_o 1 f 1 trom 1 r ) do (3.10) 

Let us introduce a new stream expression of the following 
type in Id 

I -f- 3 to k. 

The meaning of this expression is given in (3.9). The trans- 
lation of the mixed looping construct of (3*10) now can he 
explained as follows 1 

(1-^1 ton; j-^1 (^m; K-<-1 q ; L ■«- 1 to r 
return ( for each (i I, 3 in J) ; (k in K, 1 in L)do 

...)) (3.11) 

Similarly wo can translate any type of mixed looping 
construct . 

3»7 Lor each - while type of loop revisited 

Consider the following type of loop expression whoso 
translation is discussed in [AG-P78 1 in some detail. 
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( initial . x Zq 
for each, h in B while p (h,::) do 
new X ^f(bj,x) 

roturn x) (5.12) 

The main foaturo of tho trail elation ie that a signal 
stroaii S controls the roleaso of tohons from stream B into the 
loop. Or equivalently a token of stream 3 enters the loop 
on demand only. How we will describe a slight modification 
of the scheme given in [AGP 783, 

The translation of expression (5.12) can be simplified 
to the one given in Figure 5.1 provided the loop of expression 
(5.12) satisfies the following propert 3 /- P, 

p(b^,x^) = false = est 

where b^ is the ith token of stream B and x^ is tho input value 
for the ith iteration of the loop. The property p guaran.toes 
that stream B runs out of tokens exactly x-iaen tho loop predicate 
p turns false » 

In general property P does not hold for a loop. However 
wo can always convert any for oach - while loop to one for 
xdiich property P does hold good. Tbe technique is explained 
below by using tho same example (i.e, expression (5.12)). 
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However, nox.r we aesume property p is- not sritisfied by 

the loop in (3.12). 

(x, S ’ -t- ( initial 

for each b ^ B' while p(b y X } b 7 ^ £ do 
now X -e- f (b ,x) 
rot -urn x, all true ) | 

S cons ( true . S') 

B' ^ oxif (B,S, e) 

roturn x) (3.1 3) 

It is cloar that stream B' alongwith predicat o p(b,x) 
b 7 ^ s satisfies property p provided •noe tokens ax*c present«A 
in B, This is tho samo condition as in [A&P78b] , The trans- 
lation of expression (3.13) differs from tho translation of 
expression (3*12) according to the rules given in [ A&P78 ] 
only to the extent that exif and cons will be oubside the loop 

domain. ' 

3,8 Controlled generation in a for - while loop and in a pdt 

Wo consider tho translation of tho following looping 
construct 

for i from 1 to n while p(x) (3.14) 

An equivalent form involving generators will be 

for each i in I while p(x) do (3-15) 


whore I is the stream 1 t£ n. 
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TliG loop in (5.14) geiiGratos o, value of i only when 
p(z) for tliG previous value of i is true . Iloncc if n >10 
and p(x) turns false at the 10th iteration, the values 11,12, 
n for i are never generated. On the other hand, loop 
in (3.15) will always get in strea,m I tho whole soq_uencc 
1 , 2 ,..,, n oventhough it will simply absorh va^luo 11 , 12 ,..,. 

If n happens to ho a infinitoljr large number, the program 
in (3.15) will not terminate while in case of (3.14) it will. 
This descripancy can be resolved by producing the tokens of 
stream I on demand. The technique described in Section 3*7 
for generating a signal stream can be used to control the 
production of tokens in stream I. The details ane given 
in expression (3.16). 

( , , . , S’ •<- ( initial • 


for each i in I while p(i,x) A i e do 


return , . . , all true ) ; 

S - 4 - cons ( true , S')j 
I ( init ia l i 1 

for each s in S do 

if i ^n then new i i+1 | i ’ i 

else new i e; i ' e 

return all i ’ ) 


return 


) 


(3.16) 



45 


Tlio signal strecoja S must ‘be used in generating strcati 
I as opposed to just controlling its size after tho -iJ-holc stream 
I lias been generated. Por example if we write 

^ ( init ial i-^ 1 

while i <.n do 
now i -f-i+1 
retur n all i) ; 

I HI- oxi f (I', S, e) (5.17) 

then the whole purpose of stream S is dofeated, 

finally x\re discuss how this idea of controlled generation 
may he used in conduction with a pdt . A pdt is essentially a 
procedure and hence can accept a stream as an input parameter 
and produce a stream as an output parameter. A progranmer can 
generate an appropriate signal stream S and use it in enumer- 
ating tho elements of a pdt. The technique for generating 
and using signal stream is same as the one described in the 
above examples. ¥e think that all such programming should be 
oxplicitjr so that no new semantic extensions arc required, 

¥e explain by giving a. very simple example whore the 
elements of a sot arc to be enumerated until an element 
satisfies some predicate p. Lot s be a pdt representing 
a sot. 



46 


(! the Calling procedure ! 


• S '4-( initial 


for each z in X xfhilo H p(x,Y) Az 5^ e do 


return . . , , all true ) 5 
S cons ( true , S* ); 

X jonumorato 1 (2,3)5 


( 3 . 18 ) 


Internal structure of s would look something like the 
following 
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procedure sot (f,u,Vj set-gen, a, 1,3) 

! all formal parajaet er s have the usual iaeahing 
S - a stroa^i paranotor has been added! 

f = ... 

» 

0 

0 

elsoif f = ’'onuniera,to'' then RESULT ^( initia l i -«-1 

for each signal 
in S ^ 
if i then 

X ^ all] 
else X e 
return all x) 

(3.19) 


3.9 Mixed looping construct x-rith a uhile clause 

The loop of the typo for each i in I, D is J yhile 
p(i,3,x) do can be compiled in two steps. First trsjisform the 
sequential loop into a parallel loop according to the method 
discussed in section 3.2, Hence xre will got 

for each i in I ‘ ; j in J • while p(i, 3 ,x) do 
which can be translated oitlior according to the rules given in 


[AGP78 lor the rules given in section 3.7. Hence all looping 
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constructs involving st roams can be translated. 

'The ideas developed so far can bo suitably?- entendod to 
specify efficient translation of sequent ia,l and mixed loops of 
the following typo; 

for i from 1 n, 3 from 1 to ra while p(iy3,x) ^ (3.20) 

for (i from 1 to n, 3 from 1 to m) ? 

^ 1 5,2, whil o, p(ij 3 ,x) do (3.21) 

in extension of the idea present in the traasla.tion of 
expression (3,14) to expression (3.16) leads to the following 
translation of expi’ession (5.20) 

(...,, S • (initiaZ . 


fo r ^ each i ^ 1 } 3 in J while p ( i , 3 ? x ) A 

1?^ e A 3?^ e dp 


return . . . , all true) 

^ cons ( true ? S'); 

I , J ■«- ( init ial i 1 ; 3 1 

for each s in S do 

(if (i:l n) A ( 3< m) then new 3 3+I ; i ' i ; 3' ' 3 
olseif (i< n)A (3=01) then new 'if-i+l ; new 3 1 j 

i’ •♦•i; j'" D 

else 3^-*-e ) 

return all i ' , all 3' ' ) ) 


( 3 . 22 ) 
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It sliould bo noted tliat in oppression (3*22), the first loop 
satisfies property P ahd the moment i’ and 3’ get the value 
both, the loops terminate* 

A translation of mixed looping construct of (3*21) is 
given in expression (3*23) in terms of the rules used in 
expressions (3*8) and (3*22). 

.(***y 8 ^'^( jm c ial • 

for each i in I ; 3 in J ? k in K ; 1 in L 

while p(i, 3 ,k,l,x) A i^ e A3?i^ eAkj^ c A e do 


rot -urn , . . , all true ) ; 

^ cQns ( true , S’)? 

( initial i 1 ? 3-^-1 
for ea.ch s in S ^ 

(if (i-S- n) A ( 3< u) then now 3 d+'i ? i ’ •<- i? d ’ d 
olsoif (i< n)A(d=iji) then now i ^i +1 ; now 3 d ? 

i ' -f-i 5 d ' d 

else i ’ e I d ' ^ ) 

retur n a ll , i ' ? all 3 ’ ) 

^ ( initial k-*- 1 ; !•«- 1 
for each s in S do 

(if (kA q.) A(1< r) then noTj 1 1+1 l k ’ ■<- k, 1 ' 1 
olsoi f (k< q)A(l=r) then now k •^‘k+l 5 new 1+- 1 | 

k' ■’-k; 1' -f- 1 

else k'-’- e; 1'-^ e) 
return all k ' , a.11 1 ’ ) ) 


(3.23) 
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5.10 Sunmary 

In this ohaptcr \tg have modified the implementation of 
for loops from that given in [ AGP78 ] and as explained in 
Ghaptor 2. This has boon done to extend looping construct to 
include sequential and mixed type of loops. An explanation 
in Id is offered for the implementation of for oach ~ uhilo 
loop. This neu explanation with its virt^^o of being in Id is 
applicable to many programming situations whore a controlled 
generation of elements is required. At this stage it soems 
that tho only fundamonta.1 looping scheme is 

for oacli X in y in Y while p(x,y) 6 ^ 

Both the while loops and for each loops without whil e clauses 
can be explained as spocia.1 cases of the above loop. All tho 
other sequential and mixed looping constructs havo already been 
defined in terms of this fundamental parallel looping construct 
with a while clause. 

Generators as used in tho literature so far can be 
expressed in Id without any extensions, binco pdts arc 
basically procedures, controlled generation of elements even 
in case of a pdt is no problem. 
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STRSM STRUCTURES 


In this chapter wo discuss the concept of arrays of 
streaus, wiiich. will lo called stream structures , and siiow their 
usefulness in modelling the problems related to the a,rea of 
resource management. After motivating to stream structures 
in Section 4.1 , we review the dynamic streaSi construct of Id 
in Section 4.2 and show its use by an example in Section 4.3« 

In Section 4.4 it is shomi that stream structures can be 
incorporated in Id without extending the base language. ¥e 
extend the semantics of some base langua^-go opcro,tors in 
Section 4.5 to permit streams as creation time parameters for 
Id monitors. Finally in Section 4.6 a complete example showing 
the use of stream structures is discussed. 

4 . 1 Motivation s 

A problem in the aroa of resource management is how to 
maintain a queue of requests for a ro source or a group of 
resources. In many instances a distinction among requests has 
to be made depending on their certain attributes, such as 
priority etc., to implement various scheduling policies 
[Bri 73, Sha 74]. In such cases many queues have to be 
maintained to distinguish between different requests. 


1 . 

CEHIKAL 

: 54921 
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Streams in Id offers a nat'ural way to nodol the 
first-in~first-out queue , In order to maintain several 
queues a stream variable can bo defined for each queue. In 
a monitor definition in Id an entry port corresponding to 
each queue can also be defined. However, if the n-umber of 
queues is largo and dynamic addition and deletion of queues 
is required, then certainly, we cannot use the above idea. 

What wo need is a model in which we can address a queue in 
the form A [i] , where A is the group of queues and i is 
the distinguishing attribute of the queue we are referring to. 

The dynamic stream construct in Id [AGP77] offers a 
way of maintaining a variable number of queues, however, it 
imposes a restriction that all streams comprising a dynamic 
stream have to bo dealt in an uniform manner. Our main 
motivation to go for stroai^i structures is to provide a 
mechanism to model a largo and a variable number of queues in 
which individual queue can bo addressed and operations can be 
performed on its elements. 

@ 

4.2 Dynamic streams 

As described above a dynamic stream is a set of streaas 
whoso elements are to be treated in an uniform manner. Ho 

*In this chapter streams and queues will be used synorynously , 

^■This description of dynamic streams is taken from personal 
notes of Dr. Arvind and ¥il Plouffc. 
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explicit nechanisra for sGlocting a particular stroaii is 
providod. Id provides exactly one construct for tlie creation 
and nanipalation of dynamic streams. The construct is 
explained in expression (4.1). 

( dswitc h I S via L 
dp 

J ( ... ) 

dmerg e J via M) (4.1) 

The operator dswitch creates a distinct logical stream 

I . for each distinct value j in the stream L, Stream I . will 
J J 

contain only those tokens of S for which the corresponding 
token of L has the value j. As an example 

d swit ch X (ayhjCydjOyfyg j vi a [ 1y3yS^3j3^l9l3 

would create the dynamic stream I with logical streams 

^ " I- ^3 ^ ~ ^ Dyd^G j 

The operator dmergo is the inverse of dswitch and 
creates a single stream using the dynamic stream J according 
to the specification stream ¥i by removing one token from the 
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logical stroani J. -wlxon the next token fron M cairics the 

J 

Value j. As an' oxamplo, if tho value of the stream M is 
[2,5y3j1 >3,1,1 ] , and the afcream components of dynanic 
stream J are 

J-j “[UytljC ] , J 2 1 [d], ^ 

then dnergo will produce stream [ d jC, f , a,®,! , c] . 

Tho operators d switch and dmorge are dotorninistic in 
nature. The code enclosed hetweon d swit ch-dme rg e pair is 
logically created and independently acted upon hy each stream 
of a dynamic stream. Inside a d swit ch - dmerg o pain a 
programmer treats dynamic stream like an ordinary stream except 
that he cannot use ordinary streams in conjunction with 
dynamic streams. • Below wo discuss the u-interprotor semantics 
of the operators d switch and dmerge . 

4 • 2 . 1 o’ swit ch ; 

As mentioned above d switch creates a distinct logical 

stream (I-) for each distinct value (j) in tho selection 
3 

stream (L) . It does so by changing the context part of the 
activity name , ¥o give the u-interpretor semantics of 
d swit ch used in tho dynamic stream construct of Figure 4^1 . 



logical streams / 0 


I'igure 4.1 





A ly nai:' i c st r c 'iiu co jti o t ru ct 
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u.p.s.i - - input; porti (selection stream)= {<0, ,k>j1<k<n } 

port2 (data stream) ={<:5^,k>|1 

output; (dynamic stream)= 

U ( 0,.?^ est Igc n « X . count ( G. .k) >. 
1<k<n ^ m -m m 

< (u»Cj^) •p^t »i >>} 5 ^ ) s 

U {<<e^, count (j, n )> , 
j eDL ° 

< (m, j) .p.t.i »} ) 

■wliere D1 =; {jfj = C-, for some k<n } 

count (oyk) =| {i|0^=j and i < k } j 

Thus to create logical streams context part of the activity 
name is changed from u to Since a logical stream is created 

for each distinct value of 0^^, the logical streams are uniq,uely 
defined hy the context part of the activity name. A logical 
stream is treated as an ordinary stream, and, thus it cannot 
have "holes" in it, Por this reason d switch maintains the 
niamler of elements passed to each logical stream by the function 
count . As soon as an est on selection stream is encountered, 
est tokens are produced for each logical stream. 11 maintains 
all the distinct values for this purpose. 

4,2,2 dm erg e ; 

As mentioned before 
dmerge J via M 

creates a single stream using the dynamic stream J according 
to specification stream M. This is done by taking an element 
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fron tliG logical strcaa I . -wlien tho next olcncait iron tho 

J 

stroara M carries the value j. 

We give the U -interpreter senahtics of dnerge used 
in the dynanic strcaa construct of Eigure 4«1 . 'The description 
d-iaorgo is coraplicated hy tho fact that all streams of the 
dynamic stream have separa,te activity names and hence 
cannot be sent to the same operator. Thus dnerg e has to be 
broken into two primitive operators; a nerge^ and a inerge_ . 

The schematic representation of operators merge, au-d merge ^ 
is given in Eigure 4 *2. 

a. merge ; This operator operates on the control stream and 
c 

for each token received by it, a token has to be produced by 
the dynamic stream construct of Eigure 4.1 • merge^ essentially 
produces a stream of tokens for each of the merge operators. 

The kth token received by the merge operator carrying value c 
is forx-farded to the merge operator operating on the logical 
stream I to produce the kth token in the output stream. 

G 

u.p.s.i - - input ; (control stream)={<Gj^,k >| 1 :< k <_n^ } 
output -■(kj^n-^{< k, count ,k) > , 

<(u.C^) .p.merge^.i >} j 
{< est , k><u.p,t.i>} ) 
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Pigure 4.2 Schematic representation of merge^ and 

merge.* 

c 
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Since merg e^ operator is identified by the context 
(u.C^^) of the logical stream on which it is operating, the 
context part of the activity name of the control tokens sent 
to merge ^ operators is also changed to The merge^ 

opei'ator has strong similarities with the dsxfitch operator, 
however, merge produces only one final est token as opposed 

to an est for each merge . 

^ 

h. mergers A merge^ operator is needed for each logical 

stream I. of the dynamic stream I. A token produced hy the 
3 

dmerge comes from one of the merge operators. The merge 
operator which produces the kth token of the output stream is 
picked on the basis of the kth token received by the merge^ 
operator, 

(u,3).p. merge «i - - input; port 1 (control stream) 

= {<C3^^,k>| 1 < k< p^} 
port 2 (data stream) 

={<2^.k >!1< k <p^} 

output; ( stream) = U (k. <P^{<1|^» Cv> , 

< u.p.t.i >3.5 
k=p •*“ 0; C) 

It should be noted that the dynamic stream construct 
of Figure 4.1 produces valid base language program. However, 
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the base language schema of figure 4.2 will be self cleaning 
only under certain conditions and those conditions , in general? 

cannot be checked without executing the progi’am. For self 
cleaning streams C-j , C 2 ? must have the same number of each 
integer present in them, 

4.3 A disk scheduler monitor 

¥e illustrate the use of dynamic streams by inciting a 
disk scheduler. To minimize disk-head- seek-time we implement 
a scan policy in which disk head moves in one direction and 
processes all the requests that fall ahead of it. If no 
request lie ahead then the direction of scan is changed and 
the same rule is followed again. If the disk head is busy and 
a new request for cylinder c arrives, the counter count 
associated with the cylinder c is incremented. Similar to 
Hoare's monitor[Hoa74 ] we maintain a queue of requests for 
every cylinder >ath the help of a dynamic stream DRSQ, The 
scheduler produces a stream giving the cylinder number of the 
next request to be processed. This stream is then used to 
form a dynamic stream of triggers; DTRIG, which in turn is used 
to send signals to queues DREQ, 

Once a request is allowed to proceed, it calls on another 
monitor 'disk control' to actually seek the desired cylinder 
and transfer data. This monitor may contain some of the actual 
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hardware of disk controller. A replj?" from disk control 
monitor signifies that the request has teen processed. The 
disk scheduler monitor produces a result stream RESULT which 
is used to signal the scheduler that the current request 
has Tooen processed. A schematic of disk scheduler is given 
in Figure 4.3 and Id implementation is given in Figure 4*4. 

¥c will not discuss the 'disk control' monitoi*. 

4- *4 Stream structures 

As pointed out oarlior, dynamic stream construct 
provides no way of selecting a particular logical stream- 
Consider a slight modification of the problem of disk 
scheduling discussed in Section 4.3. Suppose the disk scheduler 
should access two different physical disks depending on which 
group does the cylinder number belongs to. Sol^ltion of the 
problem using the dynamic stream would require the use of a 
case statement operating on all logical streams thus no longer 
maintaining problem structure in the solution. This solution 
is also likely to be inefficient in some cases. ¥o mil 
discuss these points further in Section 4.6. 

In fact the dynamic stream construct in Id solves 
two problems associated with the resource management. ; 

1 . The d switch operator is used to form large and var- 
iable number of queues. In doing so initial 
ordering of requests is maintained only within a 
particular queue. 
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REQUEST 



Eigure 4*3 Schematic of disk scheduler monitor 
of Eigi^ro- '•■(4»4) . 



monitor disk sckoduler (do) 

! do is the disk control monitor for the disk this scheduler 
is supposed to schedule ! 

( entry REQUEST ^ 

REQCYL ^ (for each req_. in REQUEST ^ 
return all req.c) ? 

! req.c gives the cylinder numher! 

RESULT ( dswitch DRBQ ^REQUEST via REQCYL | 


DTRIG4- CYLIIUDER via CYLINDER 
do 

DRESULT for each dreq_ ^ LRBQj 

t ^ LTRIG ^ 
dres ^ use (dcydreq )' ;fhen t 
return all dres) 
dmorge DRESULT via REQCYL) 

X -e merge (REQUEST, RESULT) 5 
! This is scheduler code! 

CYLIUDBR -i- ( initial busy false ; direction ^ "up" ; 

head 0 

for each 3: in Z do 

if s.type = "request" 
then (if busy 

then new count count 

cylinder X 

else new direction (if x.c > head 

- - f^bon "up" 

else "down" ) | 


new head c ; 

new busy true ; 

cylinder -ec) 

e lse I it is a done signal! 
new count, now head, new direction, cylinder 
-'-findnext (count ,head , cylinder ) ; 
now busy ■‘■(if cylindor= X then false, 

else true ) ) 

return all, cylinder but >) 


exit. RESULT) 

ViP-i:iT>e 4.4 Code for disk scheduler monitor 
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2, Tlio dmer^o operator is used to rostorc the initial 
ordering by choosing the appropriate control stroani 
(soe the uso of stream REQCTL in figure 4.4). 

Another solution to maintain a variable number of 
queues in which individual queue can be addressed is to introduce 
array of streams -■ which will be called as S t r c am St rue t ur e . 

stream structure is a stream in which each element 
has an associated qualifier which will be callod "selector". 

The selector can be part of the activity name or part of the 
data itself, for further discussion wo will assume it to be 
the part of data. Thus no now Id constructs or base language 
operators are required to deal with stream structures, in 
clement of the stream structure is of the form: 

"data''s X, "selector": int > , k > , < activity namo>> 

where int is a selector value. ¥e will assume all selector 
Values to bo integers. A stream structure can also be 
regarded as an ordinary stream of structure values. Hence, all 
operators and constructs defined on simple streams are valid 
on stream structures also. In addition we define two Id 
procedures which arc useful when dealing with stream structures. 

a. select (A,i): A is a stream structure and i is a selector 
value. The result of procedure invocation is a stream 
containing those elements of A whose associated selector 
value equals i. Expression (4.2) gives details of the 
procedure. 
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pr PC edui^ e. s ele ct ( A, i ) 

( for each a in A do 

res (if a f ‘'selector" 3 = i then a f "data" 3 

else X) 

return all res but, X) (4*2) 

h. append (A,Bji)s A is a stream structure, B is a simple 
stream, ahd i is a selector value. Result of procedure 
invocation is a stream structure containing those elements of 
A whose selector value is not equal to i and all elements 
of B with their selector value made* equal to i. Expression 
(4.3) gives details of the procedure. 


procedure appeud (A,B,i) 

(RES1 (for each a in A ^ 

res1 (if a [ "selector" 3 = i the. n X 

else a) 

return all res1 hut X ) ; 

RES2 ■*- ( for each b in B do 

res2-<- <"data"”. b, "selector"si > 

return all res2) 

return merge. (RBS1 , RBS2) ) (4*3) ^ 

merge in the return clause of the procedure append is 
used to cater for infinite streams. It can bo replaced by 
concatenate operator, if only finite streams are being considered 



Tlie usG of mer^G malcos tliG procedure append nondeterministic 
in beliaviour. However, if we allow only for eacli loop and 
the procedure select to operate on streatu structures, then 
either all tho elomonts can he dealt in an uniform, manner or 
a particular stream can he selected. Since mer^^e does not 
change ordering of elements in component streams, tho selected 
stream is always deterministic. Thus under these limitations 
the ultimate result will always he deterministic, 

4,5 E:ct;ension of Id monitors to include streams as creation 
time parameters 

The problem of maintaining queues is solved using stream 
structures. However once selection of a particular stream of 
a stream structure is done, the position of the elements of 
the selected stream within the original stream is lost. 

However, for correct functioning of Id monitors, it is required 
that a strict correspondence between the elements of input 
and output streams he maintained , Hence, for stream struct-ures 
to he useful in resource management problems, we need a way 
to restore the original order, ¥e extend the monitors to 
include streams as creation time parameters and then we will 

*Hote if this is not the case, that is, tho answer corresponding 
to the ith token of tho input stream is in the jth position 
(j?^i) of tho output stream then the sender of the ith token 
will get the wrong answer (i.o., the ith token from the 
output stream) . 
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use the extended monitor and djmajiiic streams to alter the 
ordering of elements in a stream structure# 

¥e -will allow the streams to be parameters in the 
construct create (sec Section 5.2 of [ AG-P78 ] ), Por each 
stream parameter in create ire provide separate port in operators 
O 2 and MBEGIN. A schematic of such extension is shox-m in 
Pigure 4.5. Belo-j- vxo give the activity name manipulation by the 
operators , C 2 and MBE&Il. 

i. s This opera^tor needs no change to accomodate streams 
as creation time parameters. 

u.c.s^ .i - “ input = c^^ 

output; port1 = < (u' .c .mbogin#1 ) , 

"■ HI 

<u.c.S2«i»‘l 

port2= (u' .c^. entry .1 ) 

ii. 02^ A separate port is created for each stream parameter# 

u#c.S 2 .i - - input; port1= (u ' .c^#mbegin.1 ) 

port 2= X 

port3(strGam)= {< yjk >1 1 <.]£ ^ny) 
output; port1= <x, <u* ,Cj.,,.nbegin#1 ,1 >> 
port2(stream )={< <y»k> 

<u’.c .nbegin.1,2 » 

HI 

I 1 < h £ Uy } 
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Thus the operator will ronain in exist once until 
it either receives cst tokens on all strosjes or the monitor ^ 
object is destroyed, 

iii. liBEG-IN ; 

u ' .c^^.nibogin.l - ~ input; port1 ( simple ) =3: 

poi*t2( streaj 2 .) = {< y,lc>il <ic — n) 
out put ; port 1 ( simple ) =3c 

port 2 ( stream )= {<y,k>I 1 £k< n } 

A raonitor to alter the ordering of elements of a strean 
structure is given in expression (4,4). 


monitor nc::ts (STREiI4~ST) 

( entry SELECTOR ^ 

RESULT ■^( dsuitch DSEL-^ SELECTOR via SELECTOR? 

DSiERBAl-I-ST STREAH-ST via 
( for each s in 

STREil-I-ST do 

I'oturn all s ["selector" ]) 


do 

RES-^ ( for each ds in DS'IREAfl-ST? 

dsel in DSEL do 
return ds uhon dsel) 
dmorgo RES via SELECTOR) 


e3cit RESULT ) 


( 4 . 4 ) 
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Use of an instantiation of such a, monitor by 

use (dnextsjc), T.rhere dnexfcs is a. monitor object created from 

monitor definition nexts, uill give the next e3.ement in 

the logical streana DSTREil-I-ST. . Ihis is in fact, the nerb 

c 

element whose selector value is c in the stream supplied to 
dnear'cs at creation time. 


The effect of monitor nexts can also be achieved by 
providing an entry port for stream STRS^I-ST without extending 
the monitors to include streams as creation time parameters. 
Such a version of monitor nexts is given in expression (4.5) 


monitor nexts ( ) 

( entry selectors SELECTOR? datas STEElJi-ST 

RESULT1 ( d switch DSEL-*- SELECTOR via SELECTOR? 

DSTREil-I-ST -^STREM-ST via 
( for each s in 

STRBiO^'I-ST ^ 
return all s[ Select or”! 


do 

RES-^ ( for each ds in DSTREAM-ST 

dsel in DSBL ^ 
r eturn all ds when dsel) 
dmerge RES via SELECTOR) ? 

! we also need to acknowledge the processes sending 
elements of STRBiJI-ST at entry port "data”! 
RESULT2-*- ( for each s in STREAtI“ST do 
return all ’acknowledged’) 

exit selectors RBSUI 1 TI ? data: RESU1T2) (4.5) 
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The stream STREAti-ST is sent to an instance of nexts 
element ly element as explained in program segment of 
expression (4.6), 

dnexts create (nexts, ) 

( init ial f lag anything 
for each s in SlREAl-I-ST do 

aclc-^use (dnexts.datays) nhen flag; 
now flag -^-ack 

return ... ) (4.6) 

I)u.G to unfolding of loops in Id second iteration of loop 
in expression (4.6) may produce s before first iteration does 
so. Since the entry operator is nondeterministic, it will 
g^2.'feor the ordering of elements in STREAI^“ST. lo avoid this we 
used a flag in expression (4.6). Flag will get a new value 
for the next iteration only when the previous iteration has 
completed the use of the monitor, thus forcing serial use of 
monitor instance dnexts, ¥e want to emphasize the fact that 
any time a monitor is to be used sequentially it should be 
explicitly programmed by the programmer. Actually we are 
tempted to introduce a new U operator in the base language 
that will automatically ensure sequentiality in the use of a 
monitor. This new operator will receive an acknowledge 
signal from the entry of the monitor as soon as a token is 
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roceivod. The advaxitage is, of course, ono docs not have to 
program cxiolicit acknowledge signals, generating which can he 
quite clumsy in some cases. 

Though monitor nexts in expression (4.5) is equivalent 
to monitor nexts in expression (4.4) as far as overall 
behaviour is concerned, monitor in expression (4.4) reflects 
nature of the problem more clearly than the monitor in 
expression (4.5). Also limiting creation time parameters of a 
monitor to be simple variables is reall3^ not necessary. 

Inside monitor nexts we use the dynamic streams to 
maintain queues and palter ordering. Such a use of dynamic 
streams off ers two advantages: 

i* Dynamic streatis can be made accessible only to 
monitor nexts thus avoiding the problem of 
unintentional mixing of dynamic streams with simple 
streams by users. This also gives a kind of 
desirable modularity to the program. 

ii. Semantics of monitor nexts is easier to understand 
than the semantics of a general dynamic stream 
construct. This is due to the fact that net effect 
of monitor nexts is only to alter the ordering 
unlike dynamic streams w-hich perform tvro functions 
at a time. 

As a passing point wo would like to mention that the 
concept of monitor nexts can be applied to model next construct 
on streams. Expression (4.7) gives a monitor whose behaviour 
is equivalent to construct next. 
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monit or next (X) 

( entry REQ ^ 

7 ^ os:if (X,REQ, e ) j 

RES «e- ( for oacli reci iS ;r in Y do 

rotr.rii all y) 

e xit RES ) (4.7) 

As an example consider an Id program wlxich uses the next 
oporn,tor, 

Z ( for each b in 3 do 

^ 'fch-o^ next X 

e ls e no;rb Y) 

retur n all z) (4.8) 

The above program can be xfritton using monitor next as; 

xnext ■+- create (next ,X) ; 
ynext creat e (next ,Y ) 

Z ( initial xsig-f- anything ; ysig ^ anything 
for oacli b in B do 

if b then z -^ usp, (xnoirt, xsig) ? 

now xsig -f- zjnew ysig anything 
else z •<- use (ynext, S’-sig)? 

now xsig -f- anything ; new ysig ■«. z 

return all z) (4.9) 
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4.6 Axi oxamplo 

Consider a Eiultiprograiiinied , multiprocessor environment. 
Suppose each processor is capatlo of performing several 
different tasks, and the set of tasks performed "by any processor 
is exclusive of the sets of tasks performed by all the other 
processors. There are soversil. requests for each typo of task, 

¥e want to write an interface monitor which will schedule the 
tasks on the processors* ¥c will assume that there are onlsT" 
two processors and different task typos arc numbered from 
1 to 2n vrith 1 to n running on processor 1 and n to 2n 
running on processor 2, Real world examples of such a system 
^rould bo a system like GRAY 1 tRusTSl having separate processors 
for scalar and vector operations or a system in which one 
processor is dedicated to string operations (compila,tion etc.) 
and one procossoi' to arithmotic calculations (floating point 
arithmetic unit). Each task typo has a priority associated 
with it, and the number of requests waiting in its queue. These 
numbers arc maintained in two arrays: priority and count, A 
procedure ’’change- priority" changes the priority of tasks 
dynamically depending on the number of requests waiting. 

Another procedure "highest -priority" gives the highest 
priority task number, whoso queue is not empty. The number 
of the highest priority task is between 1 to n or n to 2n 
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dcponding on whether tho flag is sox to 1 or 2. If no such 
task is found than the procedure ’'highest-prior ity" returns X. 
Each processor has an associated monitor processor [ i] ; 

1=1 y 2 which ma3^ he tho actual hardware of the processor. This 
monitor returns its numhor i in result, "processor" to 
interface monitor when it completes tho scheduled task, A 
complete description is given in expression (4.10). Vfc 
maintain separate c^uouos for each typo of task using stream 
st ru ct ur 0 S T-itE Q , 

mo nit or interface (processor, count, priority) 

( entr y REQUEST 

I stroaies REQUEST and TRIG- are changed to 
stream structures! 

ST”I;EQ ( for each req in REQUEST ^ 
stroq 4- <"dat a" sreq, 

"selector": req. task> 
rot urn all streq) 

ST~TRIG (! TRIO- is returned by scheduler code I 
for each trig m TRIG- do 
sttrig <"data’': trig, 

"selector": trig > 
return all sttrig) 
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1IES1 ( for i from 1 ii dp 

ST--REQ1 ^ solGct (ST-RBQs i) ^ 

ST-TRIGI ^ soloot (ST-fRIG-, i) ? 

RRES1 ( for oacli strGq_1 in. ST-REQl , 

sttrigi ^ ST-fRIG-1 ^ 
re suit -^usG (procGssor[ -1] , 
strGq_1 ) 
when sttrigi 5 

rrosult -t- <”data'’; result, 
"solGctor”:i > 
r 0 turn all rresult) 
return all RRESI ) ; 
nBS2 ( for i from n to 2n do 

ST-RBQ2 4- sGlGct (ST-REQ, i) 5 
ST-TRIG2-^ select (ST-TRI&, ±); 

RRES2 4 - ( for each strGq2 in S!r“RlQ2 

sttrig2 in Sl-lRIC-2 do 
result usp (processor [2], 
streq2) 
when sttrig2; 

rrosult ■*’<"data’': result, 
"select or”; i> 
return all rresult) 
return all RRBS2) ; 

RESULT merge (RBSl , RES2) ; 

2 : ^ merge (REQUEST, RESULT); 
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! following is schodulor code* 

TRIG- -s- ( initial . . • 

for oach- x i^ 2 ^ 
if x.typo = "roq." 
then (if x.taslc:! n 

t]icn (if status [processor [ 1 ] 3=''frGG'' 
the n trig -f-.x.task 
olso now count [x.task ] ■*" 
count t x.task ] +1 ; 
change-priority (priority, 

c ount ) ; 

trig X ) 

olso ( if stc’.tus [processor [ 2 ]]=’'frGG' 
then trig *■ x.task 
olso no''.r count [ x.task 1 ^ 

count [ x.task ] +1 ? 
change-priority (priority, 

count ) 5 

trig X ) ) 

else 1 it is a done signal from processor 
monitor! 

(if X. "procossor"=1 
then trig ^ highe st - prior it y( 

priority, count, 1 ) ; 
status [ processor [ 1 ] ] +- 
( if trig= ^ then "free” 
else "husy") 
olso trig highest -priority ( 

priority , count , 2 ) 5 
status processor [ 2 ] 3 
(if trig= X then "free" 

else "busy" ) ) ' 

retTorn all trig but X) ; 
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! following is code for restoring ordering! 
rnezts -^create (ne:cts, RESULT)? 

EZ-RIS ^ ( initial flag anything 

for each req in S.EQUBST ^ 

eicros ^ vise (rnexts, req) when flag? 
new flag exres 
return a,ll esres) 

exit EX-RES) (4«10) 

Procedures "chango-priority" and '’highcst-priority” 
are easy to write and wo will not discuss them hero. 

The monitor int enf ace ,if T-jritten using dynamic streams 
will look something likes 

monit or interface (processor, count, priority) 

( entry REQUEST 6 ^ 

REQ *■ (for each req in REQUEST dp 
return all req. task) ? 

RESULT ( d switch DRBQ ■«- REQUEST via REQ? 

DTRI&“^ TRIG via TRIG 
do 

( for each dreq in DREQ? 

dtrig in DTRIG ^ 
res -s- (if dreq, task< n 

then use ( processor [1 ], 
dreq) . . . 
elseif dreq .t ask > n 
dreq, task 5. 2n 
then use 
(processor [ 2 ] , 
dreq) ... 
else 'error’ ) 


0 


) 


exit RESULT) 


dmei*go RES via REQ) 


( 4 . 1 1 ) 
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‘.n expression (4.10) tlie stream structui'cs ST-RBQ and 
ST-TRIG circulate in the loop. However, since input and output 
of streams is asynchronous, and ST-REQ and ST-TRIG are not 
altered hy the loop, all the instantiations of inner loop will 
proceed simultaneously. Thus there is no substantial loss 
of asynchrony (only that the last instantia,tion of the inner 
loop will start after n units of time). The program in 
expression (4.10) uses the select operation on stream strunturos 
whose execution time may be comparable to the execution time 
of Case statement used in expression (4.11), when the number 
of conditions are loss (say 2 or 3). However, with a large 
number of conditions execution xime of the case statement may 
be too high, and, it will also be cumbersome to write the 
predicates. The program in expression (4.10) does reflect the 
steps in the computation more clearly than the program in 
expression (4.11). 

4.7 Summary 

¥o have discussed stream structures which are usofxil 
in maintaining large and varia,ble number of queues in the 
resource management. In fact stream structures can be used 
in any place where arrays of streams are required. Rurthermero 
stream sxructures require no now Id construcls and/or base 
language operators and they are completely user-programmable. 



CHiPTER 5 


PRO&RilfflER DBPIMED CONSTRUCTS 

In this chapter we propose a mechanism in Id hy which 
new constructs can be defined, ¥e call it programmer defined 
construct . Such a mechanism is useful in abstraction of 
operations and in defining one’s oxm lang-aage. In Section 4.2 
we discuss the syntax for the definition and the use of a 
programmer defined construct and the implementation details. 

¥e clarify certain points by discussing several examples in 
Section 4.3. Piiially, in Section 4.4 we discuss the limitations 
of our approach. 

5 . 1 A case for programmer defined constructs 

Design and implementation of large and complex software 
systems, their subsequent maintenance and modification, and 
proving correctness of such systems are facilitated if we 
reduce the amount of complexity that must be considered at 
any one time. Abstraction, whether it is of operations (events) 
or data, provides a way to separate "what" from irrelevent 
"how" and thereby reduce the complexity. Data abstraction 
[Gut77, , LSAS77, .'SWL77, >/LS76] has drawn much attention recently. 
However, we would also like to view operations in an abstract 
way. To some extent, procedures in programming languages 
provide a way to the abstraction of operations. A procedure 
can be treated as a black box which performs a function and at 
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tlie time of its use one need not worry about "how” it does 
so . 

However, procedures are static in their nature, in the 
sense that they can operate only as a particular expression 
over different sets of parameter values. A more dynamic 
facility would bo one which specifies only the relationship 
among the expressions, the actual expressions being supplied 
at the time of its use [BacTSl. 

As we mentioned in Chapter 1 that most of the existing 
programming languages are becoming bulky with the addition of 
newer and newer constructs to deal with specialized situations 
or extensions. Still, they remain inherently weak because 
they can not deal with situations for which they are not 
designed. This is due to the defects at the most basic level 
in their design. Their semantics is closely coupled to 
state transition and they divide the programs into expressions 
and statements, Whereas the expressions can be combined 
very easily to form higher level programs, it is difficult to 
do so with the statements. The re suit -is that conventional 
languages are forced to have more rigid parts and less 
Variable parts. A more rational approach would be to 
provide primitive building blocks alongwith a facility which 
is helpful in building complex and specialized structures 
using these primitive building blocks. Thus one should be 
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able to create his own language tailored to his needs 
[Bac78] . 

Bearing the above two points in nind we propose a 
mechanism in Id which allows one to define his own constructs. 

¥o call them programmer defined constrv-c ts (pdcs in short). 

Such mechanisms are provided in LISP C-IcC62] and B.ED languages 
[Bac73j Bac78 ], GIU [LSAS77]and ALPH AID [3^/177 ] provide an 
abstract view of looping mechanisms. A dataflow; language 
CAJOLE [iI0S78], though in a very prelirainary development 
stage, incorporates the idea of programmer defined constructs. 

5*2 Programmer defined constructs in Id 

A programmer defined const iu.ct in Id is composed of two 
parts - its definition and its use. The definition of a pdc 
specifies the relationship among the expressions (to be supplied 
later at the time of its use) using valid Id schemas. In 
defining the relationship, place of an expression is denoted 
by a Variable enclosed in { } . ¥e will call these variables 
exp ~ Variables . Por present discussion we assume that only 
three Id schemas - block expressions, conditional expressions, 
and loop expressions, can be used inside the dofinition of a 
pdc. The use of a pdc specifies the actual expression^ and the 
Values of the arguments. These expressions aro substituted in 
place of exp variables in the definition of a pdc. This 
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substiisution is performed at run time so the recursive 
definitions are allowed. The expression obtained after 
substitution is converted to a procedure value which is then 
applied to the actual argument values specified in the use of the 
pdc. This technique of defining constructs has some similaritie 
with the well known conditional assembly of macros used in low 
level languages [ Str651. 

5.2,1 Definition of a. pdc : 

The syntax foi* defining a pdc is given informally in 
expression (5.1). 

construct [ {cplist }] g; 'iaiconstruct irordx>" {<at body :p>} 

= (<x definition of the construct X>) 

( 5 . 1 ) 

1,1 , <2 , 2 > are metasymbols, ft denotes n 

occurances of the string enclosed in 11 D and for our purpose 
n i 1 . The formal syntax of construct definition is given in 
Digure 5 .1 * 

The string K " <s construct word5>"{<sbody 3>}]l ^ specifies 
how the pdc will be written when it is used in a program. The 
exp-variable { cplist } denotes a list of variables which will 
be supplied by an use of the pdc. ¥e want to emphasize here 
that only valid Id expressions, and not Id statements, can be 
substituted in place of exp-variables i.e. variables enclosed 
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<x construct dGfinition 3 > 1 1 = construct [ c^xn-YariabloSi^ 

<x usage form (csconstruct def s>) 

< 3 t oxp-varia'blo5> identifier 20} 

■•sScusage forni2> : :=<2: construct word-body 2x2: usage form2>[J 

<x construct word-body 2> 

<3: construct word-body 2 > ;:=< 3 : construct word 3><sexp-vari able ::g> 
<s:construct word 5 > ; ;= "<3:identifier 2>" 

<s construct def x> ; ."=<s: valid extended bclu Id expression 3 E> 

■csvalid extended bclu Id expression 2 > ; := valid Id block, conditio- 
nal or loop expression or 
a construct use wi'fch 
<2 extended Id variables ±>- 

<2: extended Id vapriables s>ss= <rld variable 2 > '[] <2 exj)- variable ^ 
<«Id variable 5 > ; s= <s identifier 2> 

<3: identifier x> ; string of Englisli alphabets and special symbols 

excluding null string. 

Figure 5«1 Syntax of tlie definition of a pdc. 



in { } , As an example? we give definition of a case expression 

using oonditional expression in expression (5.2), 

construct [ {cplist} ] "case | " {pred 1 } ^ { tody 1 } 

’•"! "{pred 2 } " =>" { tody 2 } 

= {pred 1} then {tody 1 } 
elseif { pred 2 } th. en (tody 2 } 
else ) (5.2) 

Expression (5.2) does not tring out all the points which 
are important, however, it is only intended to give a flavour 
of syntax. Other points will to made clearer in later sections. 

5*2.2 Use of a pdc ; 

The syntax for the use of a pdc can te explained 
informally ty expression (5.2), 

[ ■‘^’^list H" construct word csexp 

using [<s argument list » ] (5.3) 

Forma,l synatx is given in Figure 5.2, 'exp* denotes any 
valid Id expression or a list of expressions, 'list' specifies 
the variatles used in these expressions. Actual values of 
these Variatles should te supplied from outside, ¥o have 
introduced a neir reserved word, usir^, . The list following 
using i.e. 'argument list' specifies the actual values for 
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cx construct use 5> t i= [<^ list5>]<3: use form >:> 

usin g [< 3 : argumont list 2 >] 

< 2 : list s> ; <s: identifior <2 list ^<2 idGntifior2> 

<3:uso forms> s 1 = <s construct word use»<s use form ]J 

<2 construct word usg2> 

<2construct word uso :?> s ;= <2 construct wordsxsrvalid Id exp-i-const^ 
<3:Talid Id GxprGssion+ const 2> ;s=<s: valid Id expression x> | 

<x construct use x> 

< 3 :argu.mGnt list x> ;:=<s:valid Id expression^ ^<2 argument list s> 

(1<2: Valid Id expression s> 

<Sconstract word ^ ''<2 identifier s> ” 

<e?:valid Id expression S> s:= any valid Id expression 
<Sidenbificr S>s.= string of English alphahots and special symbols 

excluding null string 

Figure 5*2 Syntax of the use of a pdc. 
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"variaDlos listod in 'list ' . Tlio correspondence is by position 
(easies'c, thougb. other formulations can be specified), 
'Argument list' may contain valid Id expressions as the values 
for the Variables listed in 'list', in uhich case expressions 
arc first evaluated and then the evaluated values are passed# 
using also specifies the scope of the pdc , 

Expression (5.4) shows the use of the pdc defined 
in expression (5.2). 

z { [ x,y ,a,b,i,n 3 "case ]" i< n”=>" x+2*a 

" !" i= n"=>" y+2*b*a 

using !x,y,o,f ,i,1 0 ] ) (5.4) 

Here we would like to point out the difference between 
X in 'list' and x in 'argument list', x in 'list' denotes 
a Variable which will be used inside the pdc, whereas, x in 
'argument list' denotes the variable (i.e., the line in base 
language graph) outside the pdc, us ing specifies an inter- 
connection betiroen them. The facility of using can be made 
general enough so that it can bo used to avoid writing 
statements in many cases. 

5,2,3 Implementation of a pdc ; 

Like a procedure va -ue , the definition of a pdc is 
translated as constant function which produces a new type of 
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Value called *pdc'. The value of the type pdc has the 
following internal representation: 

< name : pdc nane , 

usage form: the string enclosed in II B in expression 
(5.1 ) 

definition: definition of the pdc > 

pdc name is obtained by concatenating all the construct 
words. The translation of expression (5.2) is shown in 
Figure 5.3. 

The use of a pdc is translated as a function evalc. The 
inputs to the function evalc are: 

1 , pdc definition value. 

2, A structure containing 'list' and the actual 
expressions in the form of strings. For future 
reference this structure will be called oxiovalue . 

3 The actual values of arguments as given in 
' argument list ' , 

The fimction evalc evaluates the pdc and its outputs 
are the outputs of the pdc expression. Figure 5.4 shows the 
translation of expression ( 5 . 4 ). 

The function evalc is not implemented as a primitive 
operator. It is composed of two operators - substi'bute, and 
apply. Figure 5.5 shows the internal structure of evalc and 
one may refer to it to understand the functions of two 
operators, which are discussed below. 



89 



f.;triggor 

<nanio: case | 

’ ' ■ " ' ' ' ' ' " " * 

= >I => 

usage; "case 

1 " {predD " => " {body1 } 

" I" {prod 2} " = >" {body2 } 

definition; 

(iff predl > then fhodyl } 


clseif {prod2 >thon {■body2 } 


else ) > 


value of type pdc 

(pdc definition value) 

W 


Figure 5.3 Translation of the definition of 
pdo of expression (5.2). 



pdc du'fiiii'tion 
va3-ae 

cnce j :> ( > 



cxp'Val’ue 
<1 :x,y ,11 


I'Mcnire b *4 


Trai'isla'^'^ion o.‘ uloc uoe oi' -i pdc 
( o;mre c ai Oi ( 5 o4 ) ) • 


VTi Vj3 









92 


a . sub st it II to ; 

It performs two functions - it substitutes tbo actual 
expressions in place of exp-variables and then it creates a 
new procodure value using substituted definition. If the data 
structure of Id expressions is represented in the form of 
structure or string values then no new opera,tor except a coercior 
function from structure or string to procedure is required. The 
created procedure value is passed to tho apply operator. The 
actual expressions arc obtained from structure expvaluo. The 
correspondence between actual expressions and exp-variables 
is decided using usage part of pdc definition value and is 
by position i.o, oxpvalue.1 corresponds to {cplist } and so on, 
Uame of the created procedure value is the first construct 
word and formal paranctor list of the procodure value is the 
actual list corresponding to { cplist }. To allow for recursive 
definition of a pdc, pdc definition value is passed to the 
procedure value as a "freozod” argument. 

u.c.s^.i - - input; port 1 (pdc definition value) = c^ 

port 2 = expvaluc 

out put « ere at 0 pr o c ( sub s t ( c^ , expvalue ) ) >, 

subst performs string substitution and it can be 
expressed as an Id procedure. However, ere ate pro c converts 
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tho substituted dofinition. to a procoduro value and cannot 
bo expressed in Id. The procoduro value passed to apply 
operator at tbc execution time of expression (5.4) is given 
by q_ in expression (5.5). 

P procoduro case (construct, x,y,a,b,i,n) 

( j^f i< n then x+2*a 
elsoif i = n then y+2*b*a 
else ) I 

1 compose (p,< case | =>]=> ,,,,,, > ) (5.5) 

b . apply ; 

It takes the procedure value which is passed to it by 
the operator substitute and applies it to xho actual arguments. 
The results are passed to the program segment where construct 
is used. This operator is discussed in some detail in 
Section 2.3. 

5*3 Some oxamplos 

In this section we will discuss some examples of pdcs 
to illustrate some of the points relevant to their definition 
and their use. 

a . A while loop ; 

Expression (5.6) gives recursive definition of a pdc 
which is equivalent to the while loop in Id. Expression 
(5.7) shows its use. 
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construct [{ cplist) ] "while'' { predicate} "do" 

{ body} 

= (if { prodicate } then [{ cplist }] 

'Miilo" {predicate }"do" 
{body} 
usin^ [{body}] 
else {cplist} ) (5*6) 


[sum, x,i,n ] "while" i<_n "do" 

sum +x,x,i+1 ,n 

usin^ [sumo, xo,1,10] (5.7) 

Values returned by expression (5.7) are the final values 
of the expressions sum+x, x, i+1 , n. This example brings out 
a restriction i.e. use of any recursively defined pdc should 
return the values for all the variables specified in its 'list', 

• A for-while loop ; 

¥o implement a for-while loop using the pdc mechanism 
and the for each-while loop. The implementation is based on 
the translation of for-while loop into a for each - while loop 
as discussed in Chapter 5. Tb-O definition of the construct 
is given in expression (5.8), 
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const ruct r {cplist} ]''for"{var} "from” { lower limit} 

"to" {upper limit y'lDy” { step} 

"whilo" {prod.} "do" 

{"body } 

"return" { explist } 

= ( 'local' . {explist} j S' ■<-( initial -rcnlist T-^-fenlist i- 

for each {var }in I 
while {prod}A{var }9^ e do 
new ({ cplist })-«-{ hody} 
retum { expli st } , all true) j 

COH.S ( true , S' )5 

* * 

( initial j 4- {lower limit } 
for each s in S ^ ■ 

if ]<-( upper limit } thon new 3 -t- 3+ {step } 5 

j ' •<- 3 

els e new 3 4-e 
3 ' e 


return all 3 ' ) 5 

return } local*. I explist } ) (5.8) 


The use of tlie ahovo construct is shown in expression 


(5.9) 
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[ sum, p,q,r,n,a ] "for” 1 "from" p "to” q "by" r 

"•while" s'um < n "do" 

sum+i*ayp,q,r ,n,a 
"ret-urn" 3*sum 

using r sumo, 1,10,2,s,bi (5.9) 

¥o used tho rosorved word now in a rather different 
manner in expression (5.8). If we assume that{ cplist}^ a,b,c 
then at tho time of substitution new ( { cplist} ) will be 
converted to new a, new b, now c* ¥e have also introduced 
a now way of generating variable names. 'local explist} 
means that string 'local' is concatenated with all the strings 
occuring in {explist} and now variable names are formed. As 
an example, if {explist} = x,x+y then 

' local ' . {explist }= localx^localx+y . 
localx+y is the name of a variable. Tho need to do this stems 
from tho single assignment property of Id, 

c . A for loop that returns streams ; 

Expression (5.10) gives the definition of a pdc 
which is equivalent to tho Id for loop with return all 
construct. Expression (5.11) shows how it can be used in 


a program 
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^qs-struc t^ [{cplist }] '’for"{var} "from" {lower 'limit} 

"to" { upper limit} "do" 

{ body } 

"return" { explist 1 }"all" {ezplist 2} 

« ( iK.i'feial} cplist }^{cplist} ; { var }-«-{lower limit } 
while {Tar }^ {upper limit } do 
new ( { cplist })-<-{ body } 5 “ 
now {Tar} -<-{ var } + 1 
return { explist 1 } , all ({explist 2})) 

( 5 . 10 ) 


[x,y,p,n3 "for" i "from" p "to" n "do" 

f(x,y,i), f'(x,y,i), pjn 
"return" x,y "all" g(x,y ,i) >g’ (x,y >i) 
using [xo,yo,1,10 ] (5.11) 

In this example we used a while Icop to define a for 
loop. In expression (5.10) the use of all is similar to the 
use of new in expression (5.8), 

• A sequential loop construct ; 

¥e now implement a sequential for each loop construct 
as a pdc. Our implementation is based on translation given in 
Chapter 3 (expression (3.5))* The definition of the pdc is 
given in expression (5.12) and its use in expression (5.13). 
This example brings out some of the limitations of our approach. 
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construct [{cplist } ] ''for each" { var 1 } "in" {streaml 

{ vai 2 } *!in"{streasi 2 }"do" 

{ 130(17 } 

"roturn" { cxplist } 

= (I ' ,J’ ( f p r each i in {stroaml } do 

( toi" each j in {Btronn 2 
roturn ail i, all 3 ) 
roturn all I ’ , all J ’ ) 
return ( initial { cplist }-t- {cplist} 

for each { var1 } in I’?{var2}in J' do 
new ( { cplist} ) - 5 -{hody } 
roturn { explist} )) ( 5 * 12 ) 

[x,y,I,J ] "for each" i "in" I 3 "in" J "do" 

f(x,i, 3 ), fCy^ijj) 

"return" x,y 

usinis; [xo,yo,I,J] (5.13) 

Since the values of tho streams I and J should he 
supplied from outside, they occur in the 'list’ in expression 
(5,13). At tho time of substitution, { cplist} = x,y,I,J and 
thus statement new ( { cplist })-*-( body }will be translated as 

new X , now y , new I , now J -«- { bo dy } • 

This will result in circulation of streams I and J in the 
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second loop of esprossion (5.12). Circulation of strcaias is 
to be avoided for the obvious reasons of officioncy. In fact 
in tMs ease second loop never uses the streams I and J. in 
optimising compiler may detect this fact and treat I and J as 
dead variables. 

Away to avoid suda a circulation of streams would be 
to define a deletion operation on { cplist } . If we denote 
the deletion operation by - then wo can write 

new ( {cplist}' - {streami } - {stream2 }) -(-{body } 

which, when translated at the substitution time, would result 
in 

new X, new y -(- {body}. 

Then one can also think of defining a complementary operation 
addition on { cplist } . 

5 *4 limitations of our approach 

¥e pointed out a limitation of our approach in 
example (d) in Section 5.3 and suggested a solution. The 
limitation arose from our nood to distinguish between 
circulating and uncirculating variables in a loop expression 
for the reasons of efficiency. Sometimes a programmer may 
want to circulate a stream to obtain dosired results. Our 
proposed solution is neither elegant nor general enough. 
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It also incroases the complerity of •suhst* in tho implemen- 
tation. A general solution to disbinguidi circulating variables 
from uncirculating variables will require a complete analysis 
of the program. 

Second limitation or restriction is pointed out in 
exajiiplo (a) in Section 5.3>i.o. a recursively defined pdc 
should return values for all the variables in 'list'. 

Finally wc would like to point out that our approach 
is not dynamic enough. Consider tho definition of a case 
expression as given in expression (5.2). This expression can 
deal with only two cases. We have to define separate case 
expressions to deal with three cases, four cases and so on. 

A general case expression dealing with any number of cases 
cannot bo defined in our model because a pdc is ultimately 
converted to a procedure and thus cannot model dynamicness 
in its definition itself. Conversion of a pdc to a procedure 
also reduces the interaction between tho use of the pdc and 
tho program where it is being used. 

5.5 Summary 

In this chapter we have discussed the definition, the 


use, and tho implementation of programmer defined constructs 
in Id. Programmer defined constructs are useful in abstraction 



of operations and in defining one's own language. The 
definition of a pdc specifies the relationstiip aiiong 
expressions in torms of Id schemas and dummy expressions. 
The actual expressions are supplied hy the use of a pdc. 
To bring out certain important points and limitations 
of our approach we have discussed sovoral examples. 



CH^ER 6 


CONCLUSIONS 


In this thesis we have proposed certain extensions to 
the high level data flow language Id so that its basic 
mechanisms can be fully exploited. It is evident from the 
discussions in Chapter 3 and 4 that some of these extensions, 
can be incorporated without any maDor alteration in the set 
of base language operators. An alternate translation of the 
fon loop and the for each-while loop as discussed in Chapter 3, 
enables us to incorporate sequential and mixed looping 
constructs and to enumerate the elements of a pdt in a 
controlled fashion. Similarly in Chapter 4 a sli^t modification 
of monitors enabled us to exploit the stream structures in the 
resource management problems. This points to the fact that 
the basic mechanisms in Id are powerful enough and their full 
potential is yet to be realized . In Chapter 5 programmer 
defined constructs were proposed as an addition to the basic 
mechanisms in Id. In fact the pdcs can be used to implement 
most of the constructs discussed in Chapter 3 and thus 
effectively reduce the size of the language. 

Many ideas from Id aid this thesis can also be e^rt ended 
to the conventional languages. The structure of the looping 
constructs in Id explicitly specifies the initialization 



of tliG loop Variables, a^id, aJi Id loop can terminate only 
wiien tlie associated predicate tixrns false. Sucb. a structure 
of loops in a conventional language will facilitate program 
verification. An equivalent of parallel for each - while 
loop construct alongwith the generators will be able to 
model nearly all looping constructs in a conventional 
programming language. Recent languages such as AlPHARD have 
adopted such a. view of loop constructs. 

Another idea which can be extended to conventional 
programming languages is that of progranmor defined constructs 
typo. Using the conventions of Chapter 5, below we briefly 
outline how pdcs can be incorporated in the conventional 
languages? 

Whenever a construct definition is encountered, it is 
entered in a structure, say environment . The user (always) 
specifies the name of the environment he will bo using during 
the execution of his program. Initially environment may 
bo an empty structure, liihenever a construct use is encountered 
it is translated into two statements? 

1 . a call to a system procedure evalc with the name 
of the construct and a structure containing actual 
expressions , 

2. a call to the procedure, whose name is the first 
construct word, with the arguments specified in the 
argument list of the construct use. 
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The system procedure oTalc substitutes the actual 
expressions in the construct definition, creates a procedure 
from the substituted definition, and then calls the 
compiler to translate the created procedure. xL dynamic 
linking and loading facility will make the procedure a.vailablc 
to the program, for incorporation of the mechanism in the 
languages which do not view the procedures as functions, the 
{cplist} needs to bo extended to include the variables whoso 
Values are being returned by the construct. The arguments 
are transferred using 'call by value'. 

During' the course of this work wo recognized many areas 
xirhich are still unexplored or partially explored* Our 
discussion on pdcs is certainly not the last word on the 
subject. There are certain limitations in the proposed 
approach and it would bo worthwhile to investigate how these 
limitations can be removed from the present frame work. 

Another area of interest is the specification of a minimal 
set of Id constructs which alongwith the facility of pdcs 
are powerful enough to model any programming problem. In 
specifying such a minimal sot, the efficiency consideration 
should not be unduly compromised. Also the constructs in 
the Tni.ni. Tn al sct should not be at such a primitive level that 
one has to deal with the base language. 
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Beccnt Turing locturo Toy J« Backus t Bac78 ] lias 
■brought functional forms of programming languages into 
vogue. At this stage "we speculate that if the unravolling 
interpreter can be malo to execute functional progx’ams 
efficiently, then the resulting system will be able to do 
away with most of the objections against conventional systems 
(both software and hardware) and can emerge as a powerful 
next generation system. 
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